Move all of this out of credential/. SessionKerberos, build_session_kdc_config (line 179), principal_for_realm, kerberos_salt, synthetic_realm, encrypt_with_kerberos, random_32_bytes, plus the hardcoded service_user_name: "jet" and max_time_skew: 300 — all of this is Kerberos/CredSSP session glue that has no business inside what used to be a protocol-neutral credential store.

Suggested layout: a new rdp_proxy::kerberos_session (or credssp_session) submodule owns the SessionKerberos type and the KDC config builder. InjectionState in credential/ becomes just { mapping, target_hostname }. The Arc<SessionKerberos> is either lazily derived on first CredSSP use, or stored in a parallel HashMap<Uuid, Arc<SessionKerberos>> owned by the RDP layer (keyed by the same UUID — see point 2 in the summary, that UUID should be the association-token JTI).

This also lets CleartextAppCredentialMapping::encrypt_with_kerberos go back to a plain encrypt, so non-Kerberos use of the store stops minting AES-256 keys it never uses.

removd from credential/
refactored everything you mentioned here into credential_injection_kdc.rs

About the http://cred.invalid/<id> trampoline: I see why you reached for it (sspi-rs's CredSSP server config exposes kdc_url: Option<Url>, and you needed a way to dispatch a synthetic in-process "KDC"), but the implementation is heavier than the idea. Three concrete asks:

1. Verify whether sspi-rs offers a custom KDC dispatcher API (trait object, async closure, KdcClient-like abstraction). If yes — use it; the URL trick goes away and CredentialStoreHandle no longer needs to be threaded through perform_credssp_with_client → process_authentication_with_client → resolve_server_generator → send_network_request.

2. If no clean API exists in sspi-rs, that's fine for now (sspi-rs is ours — Devolutions/sspi-rs), but please open a GitHub issue against sspi-rs asking for a pluggable KDC dispatcher and link it from a // TODO(sspi-rs#NNN) comment here. We can keep a workaround in this PR to unblock; the cleanup lands when sspi-rs ships the API.

3. Even with the workaround, please localize the interception. Right now send_network_request is a generic Kerberos-network helper that knows about "cred.invalid". Push the loopback dispatch into a non-generic function (closed over Arc<SessionKerberos> + mapping + target_hostname already in scope at build_credential_injection_server_kerberos_config), and keep the generic helper unaware of the magic hostname.

Also related: kdc_proxy_http_client() (line 653) and the "http" | "https" non-loopback branch (line 681) appear to have no real caller in this PR — sspi-rs only emits tcp:///udp:// in the non-injection path and http://cred.invalid/... in the injection path. Either delete this branch or document the external use case it's meant to serve (an undocumented "session token can point at arbitrary HTTP host" capability would be a security concern).

cc Pavlo Myroniuk (@TheBestTvarynka)

Benoît Cortier (@CBenoit), currently, the sspi-rs does not have such an API. We need to implement it. I created an issue and described the situation there: Devolutions/sspi-rs#664. Feel free to edit and add more context.

irvingouj@Devolutions (@irvingoujAtDevolution), you can replace TODO(sspi-rs#NNN) with TODO(sspi-rs#664 in the code

updated

Test coverage on CredentialStore mechanics is good. Three branches in this PR are still uncovered and I think are reachable from in-process tests (no real RDP client needed):

• kdc_proxy::enforce_realm_token_match bypass under disable_token_validation.
• kdc_proxy::process_credential_injection realm-fallback when the envelope realm is missing.
• rdp_proxy::send_in_process_kdc_request parses the URL path into a UUID, looks up the entry, and dispatches.

Full end-to-end CredSSP testing would need an actual RDP client and isn't the goal here — that's a welcome future improvement. Please add the easy-to-write ones if time permits; otherwise a tracked follow-up PR is fine.

At a glance, it seems to me that this module should be left untouched, in favor of lazily deriving the necessary elements in the kdc_proxy module, when necessary. It’s possible to obtain the original token from the jet_cred_id claim in the KDC token (it’s in the CredentialEntry that we can retrieve from the credential store handle using this ID). It’s then possible to extract the target_hostname. This avoids all the eager logic of pre-extracting more stuff than actually necessary. Again, this module should stay protocol-agnostic for the most part, and the new InjectionState seems to be designed with RDP in mind. Since it does not seem necessary to store such extra information (we can retrieve that from the token lazily at the most relevant place), we should do so in order to keep the code clean. A side effect of that is that the preflight module does not need to change either. A side benefit is that it completely removes some invalid states, making the code overall more straightforward.

This can be removed